Crate iop_keyvault
source · [−]Expand description
Keyvault
Keyvault is a general purpose hierarchical deterministic (HD) generator for asymmetric keys. It is based on the same concepts as a Bitcoin HD-wallet and is built on the same specifications like HD wallets of Bip32, Mnemonic word lists of Bip39 and Purpose fields of Bip43.
Though keyvault is capable of generating wallet addresses as defined in Multi-Account cryptocurrency wallets of Bip44, it is not only an address generator for multiple cryptocurrencies. Keyvault can also derive all the keys you might need in other software stacks and aims to be your all-in-one Swiss Army knife identity manager.
Keyvault can
- use the same seed to derive keys with multiple cipher suites, currently
ed25519andsecp256k1 - use any purpose field and account hierarchy, not only Bip43 and Bip44
- handle several purposes (i.e. attached subhierarchies) at the same time
- be used from other platforms via its C and WebAssembly bindings
Keyvault was originally created as part of the Mercury communication protocol but being a general-purpose tool it was reused in other components as well, hence was separated into its own repository then finally merged into this monorepository.
For more information on this crate and potential usage, see the IOP developer site.
Modules
SLIP-0010 compatible Ed25519 cryptography that allows child key derivation. There are alternative Ed25519-based implementations in other projects that are incompatible with SLIP-0010, so make sure this is the right derivation method for your use-case.
A thin integration of Argon2i and XChaCha20Poly1305 algorithms from the orion crate to encrypt/decrypt in-memory blobs with a password.
A type-erased version of AsymmetricCrypto and KeyDerivationCrypto. Serialized versions
of crypto concepts, like KeyId, PublicKey, PrivateKey, Signature,
ExtendedPrivateKey and ExtendedPublicKey can be all deserialized into
their MultiCipher versions.
This allows multiple cryptographic algorithms to co-exist in a software, which is needed
during migration of a single software to a new cryptography, or which is the status quo in
larger software ecosystems.
SLIP-0010 and BIP-0032 compatible Secp256k1 cryptography that allows child key derivation.
Structs
Entry point to generate extended private keys in a hierarchical deterministic wallet starting from a seed based on the BIP-0032 standard (and the SLIP-0010 for crypto suites other than Secp256k1).
In BIP-0032 each extended private key has the same operations, independently from the actual path. This struct represents such an extended private key in a given subtree.
In BIP-0032 a neutered extended private key is an extended public key. This struct represents such an extended public key in a given subtree. It is able to do normal (public) derivation, signature verification, creating and validating key identifiers
Tool for generating, validating and parsing BIP39 phrases in different supported languages.
A thin wrapper on top of a BIP39 phrase with a known language
Entry point to generate a hierarchical deterministic wallet using the BIP-0044 standard. It is a more structured way to use the same seed for multiple coins, each with multiple accounts, each accounts with a new key for each transaction request. The standard is built on BIP-0043 using the purpose code 44. And BIP-0043 itself uses BIP-0032 to derive all nodes from a single master extended private key.
Represents a given account of a given coin in the BIP32 tree.
Valid operations for a bip44 account.
Represents a given coin in the BIP32 tree.
Valid operations for a bip44 coin.
Represents a key with a given index within a sub-account used on the chain for storing balance or authenticating actions.
Valid operations for a bip44 key.
Represents a given account of a given coin in the BIP32 tree.
Represents a public key with a given index used on the chain for verifying signatures or validating key identifiers.
A sub-account of a given account on a given coin that is either used for external keys (receiving addresses) or internal keys (change addresses). Some implementations do not distinguish these and just always use receiving addresses.
A sub-account of a given account on a given coin that is either used for external keys (receiving addresses) or internal keys (change addresses). Some implementations do not distinguish these and just always use receiving addresses.
Valid operations for a bip44 sub-account.
A registry of all networks implemented in this crate.
An absolute BIP32 derivation path that starts from the master keypair. This is useful to create a hierarchical deterministic tree of keypairs for any cryptography that supports child key derivation.
The seed used for BIP32 derivations. A seed cannot be turned back into a phrase, because there is salted hashing involed in creating it from the BIP39 mnemonic phrase.
Enums
Enumeration used for distinguishing external keys (receiving addresses) from internal keys (change addresses). This distinction might help in accounting.
Constants
It might sound a bit pedantic, but some Network trait methods return fixed length byte array static borrows instead of single bytes.
Extended public and private keys use version bytes to help finding out how these keys are used on the blockchain and which blockchains they are used on
Unicode code point for planet mercury
Traits
An implementation of this trait defines a family of types that fit together perfectly to form a cryptography using asymmetric keypairs.
Extended private key not only contains a private key, but also a chain code that is some additional entropy that is used to derive child keys. Some cryptographic suites implement both normal (public) and hardened (private) derivation, some, like Ed25519 is missing normal derivation and just err when called.
Extended public key is a neutered extended private key that contains the public key that belongs to the private key in that, but it also contains the chain code so it can be used in normal (public) derivation. Some cryptographic suites do not have normal derivation and those are free to implement extended public keys containing only the public key.
An implementation of this trait defines a family of types that fit together to extend AsymmetricCrypto
with the ability to have a hierarchical deterministic wallet, so a tree of private and public keys all
derived from a single master secret.
Convinience wrapper trait covering functionality of Message Authentication algorithms.
Strategy that can be implemented for different clones of the Bitcoin network. It is a trait rather than an enumeration to leave it open for extensions outside this crate. A few example implementations can be found under the network submodules.
A private key (also called secret key or sk in some literature) is the part of an asymmetric keypair which is never shared with anyone. It is used to sign a message sent to any recipient or to decrypt a message that was sent encrypted from any recipients.
A public key (also called shared key or pk in some literature) is that part of an asymmetric keypair
which can be used to verify the authenticity of the sender of a message or to encrypt a message that
can only be decrypted by a single recipient. In both cases this other party owns the PrivateKey
part of the keypair and never shares it with anyone else.
The operations required to support SLIP-0010
Type Definitions
The hashing algorithm used for deriving child keys in SLIP-0010
Result<T, Error>